(レポート) DVO313: Next Generation Applications with Amazon ECS #reinvent
こんにちは、せーの@ラスベガスです。AWS Re:Invent 2015の会場に来ております。セッション「Next Generation Applications with Amazon ECS」はアメリカのMeteorというところが先日発表した新サービス「Meteor Galaxy」がどのように構築されているか、というセッションです。
前提知識
「Meteor Galaxy」とはアメリカMeteor社が10/5に発表した新サービス。クライアントもサーバーも全てJavaScriptで記述するアプリケーションプラットフォーム「Meteor」を自由にデプロイでき、ロギングやSSL化など必要なオプションが揃ったクラウドプラットフォーム。高可用が特徴で、ビジネス用途にも耐えられる。
- MeteorはオープンソースのJavaScript用のモバイル&Webアプリプラットフォーム
- JavaでいうJVM, .NETでいうCLR
- 「Galaxy」が中で動いている
レポート
Galaxyの構成
- Amazon ECSで構築している
- ELBがエンドポイントになっている
- 一次受けのProxyで受けたら内容に応じて必要なコンテナにリクエストを投げる
- ProxyとコンテナはAZをまたがってもよい
Connected Clientとは
- C/S, Webの次にくるもの
- クライアントとサーバーをステートフルにつなぐ
JavaScriptとコンテナ
- JavaScriptはクロスプラットフォームアプリの開発では最も理にかなった言語
- 開発にはJavaScript一択でよい
- モダンなアプリに必要なDevOpsはもう少し複数であるべき
- アプリケーションをコンテナにいれて複数用意することでスケールやスピンアップが早くなる
ECSを選択
- ECSはKubernatesやMarathonと違ってAWSマネージドのサービスなのでインフラに関して担保してくれる
- 複数のAZをまたぐことがサポートされているので信頼性が高く、ダウンタイムもない
実装
- フロントエンドとバックエンドを[App State]というDBでつなぐ
- バックエンドは複数のクラスタを起動させる
- ELBを入力ポイントとしてpublicなproxyにホップしていく
- galaxy ui もgalaxyの中にuser appとしてつながっている
- bootstrapとしてすぐに使えるようにこれらをcloudformationで構築している
ECS Deep Dive
- アプリケーションの再起動には回数制限とBackoffポリシーをつけたかった
- ユーザーは現在のコンテナの状態を目に見える形で知りたい
- Task managementをECSは提供してくれる
- 高可用なアプリコンテナはAZを通して分散させる必要がある。
- 各コンテナはproxyやスケジューラが稼働する容量が必要
- ECSなら1500行以内でその設定が可能
State Sync
- PROXYはランダムにコネクタを選ぶ
- cookieが紐付いているのでどこに繋がるかわかる(sticky session)
- バックエンドのコンテナがfailした場合、proxyがヘルスチェックして新しいcookieを振る
- 新しい場合ECSのクラスタをコピーしてローリングアップデートする
- バージョンが新しくなったらproxyに通知古いcoockieを捨てて新しいバージョンに繋がる。
- galaxyは疎結合
Galaxyのこれから
- マルチクラスタ化
- マルチリージョン対応
- オンプレ対応
- 無料枠&無料インスタンス枠
まとめ
実際にローンチしたばかりの最新サービスの中身を聞けることはなかなか無いのでセッションも盛況でした。Q&Aもとても活発でした。